前沿：在使用ViewPager和fragment的时候，如果不了解其运行机制，就会造成网络请求滥用和界面的过度绘制，使界面出现卡顿的现象，所以今天开篇文章来记录这一类的问题，并推荐一种好的解决方案出来
-
先介绍一波加载的时候会调用哪些方法吧
//对用户可见发生改变时候调用 setUserVisibleHint(isVisibleToUser: Boolean) onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View? onViewCreated(view: View?, savedInstanceState: Bundle?) onDestroyView()
根据我们使用viewpager的常识知道默认情况下他会加载选中页的两边，这是因为他的
getOffscreenPageLimit() 默认等于1
先上传一张图片，来模拟一下场景
如图，头顶是一个tablayout，下边是我们的viewpager和fragment，首次加载的时候我们会加载1，2两个fragment，这看上去好像是没有问题的
fragment 1 ， 2所走的生命周期包括
setUserVisibleHint(isVisibleToUser: Boolean)
onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View?
onViewCreated(view: View?, savedInstanceState: Bundle?)
我们接下来滑动到第三个fragment，会保存下来的fragment包括2 ，3 ，4，而第一个会销毁掉
fragment 1 的生命周期会发生如下变化
onDestroyView()
那当我们再次回到fragment 1 的时候 因为我们的视图已经销毁掉了 ，所以我们会再次创建我们的视图，生命周期如下
onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View?
onViewCreated(view: View?, savedInstanceState: Bundle?)
现在，我们可以思考一下，这中间是否有一些不必要的过程，我们可以避免掉，前边我们讲过，加载选中视图的两边和一个值有关的offscreenPageLimit，那我们依照着这个思路来处理一下，将offscreenPageLimit的值设置为fragments的size - 1，不就可以完全不会走onDestroyView()了吗，能够避免视图的销毁和重新创建。
这么一想好像蛮对的哈，但是我们的一进来就创建6个View，发送6个网络请求，这真的合理吗？如果你的代码也不怎么规范，或者后端的哥们不给力，你要做的操作将会更多，这显然不是很合理的。
细心的你们肯定已经发现了最上面还有一个方法我们没有用到
setUserVisibleHint(isVisibleToUser: Boolean)
这个方法的意思的对用户可见的时候进行提示，当对用户可见的时候isVisibleToUser为true，反之false，这个方法在初始化的时候是在onCreate()之前调用的
语言是苍白的，先上代码再说
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
if (rootView == null) {
rootView = inflater.inflate(layoutId, container, false)
}
return rootView
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
if (!isInitUi) {
isInitUi = true
initUiAndListener()
if (!isRequest) {
isRequest = true
net()
}
}
}
override fun setUserVisibleHint(isVisibleToUser: Boolean) {
super.setUserVisibleHint(isVisibleToUser)
if (isVisibleToUser && !isRequest && isInitUi) {
isRequest = true
net()
}
}
分析如下：
- onCreateView：首先我们在创建View的时候提取了成员变量，判断他是否为null，为null在创建View，这样就解决了重复创建View的问题。
- onViewCreated：然后在 initUiAndListener()里面初始化一些控件的操作，因为涉及到布局被销毁的情况，所以在布局被重新创建的时候 onViewCreated()会被重新创建调用一次，这个在普通情况下是没有感知的，如果是你在里面做了添加头布局的操作就会出现很明显的bug，和当前fragment超出了offscreenPageLimit的限制过后，再返回当前fragment就会多出一个头布局，所以，我们这里用布尔值做了一个控制，这就解决了重复初始化的问题。
- setUserVisibleHint：这个方法主要是针对我们的网络请求，做的一个简单封装，只要界面对用户可见，并且没有请求过网络的，才去做网络请求，这样就解决了重复请求网络的问题。
最后附上完整的懒加载代码：
abstract class LazyFragment : Fragment() {
var mContext: Context? = null
private var rootView: View? = null
var isRequest = false
var isInitUi = false
@get:LayoutRes
abstract val layoutId: Int
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
if (rootView == null) {
rootView = inflater.inflate(layoutId, container, false)
}
return rootView
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
if (!isInitUi) {
isInitUi = true
initUiAndListener()
if (!isRequest&& userVisibleHint) {
isRequest = true
net()
}
}
}
override fun onAttach(context: Context?) {
super.onAttach(context)
mContext = context
}
abstract fun initUiAndListener()
abstract fun net()
override fun setUserVisibleHint(isVisibleToUser: Boolean) {
super.setUserVisibleHint(isVisibleToUser)
if (isVisibleToUser && !isRequest && isInitUi) {
isRequest = true
net()
}
}
}
感谢大雨的指正，相关代码已修改，这个算是一个完整版吧
全剧终
